- introduce a `fs` package for function state related classes
- add `FunctionConfig` for user defined function configurations
- add `CmdFunctions`: it takes a yaml file and also command parameters

Signed-off-by: xiaolong.ran <ranxiaolong716@gmail.com>

Master Issue: #4 

This is the request produce  implementation.
Basic logic:
- For passed in PartitionTopic, create related Pulsar persistent topic.
- For passed in Kafka Records, write data to related pulsar persistent topic.

Master Issue: #4 

This is the request Fetch implementation.
Basic logic: For each Fetch request from a partition, create and maintain a NonDurableCursor to read from backed PersistentTopic.

** changes **
- Add basic code implementation
- Add unit tests.

Master Issue: #4 

*Motivation*

Support Kafka group coordinator protocols.

Master Issue: #4 

*Motivation*

Support storing and committing offsets in group metadata manager.

… Downgrading debezium to the same version as apache. (#4)

…SslContexts (PIP-478 FIX-6)

Motivation: apply PIP-478's own anti-kitchen-sink philosophy (Motivation #2/apache#4) to
the TLS util layer. The generic org.apache.pulsar.common.util.SecurityUtility grab-bag
mixes three unrelated concerns (PEM parsing, JCA/JCE provider resolution, JDK SSLContext
assembly) plus dead legacy Netty/rotation helpers. SecurityUtility carries no
@InterfaceStability and has no client-api importer, so it is internal and safe to
decompose.

Modifications: introduce three single-concern containers in a new package
org.apache.pulsar.common.util.tls (kept out of the dependency-light pulsar-common-api;
these pull BouncyCastle/Netty), each holding exactly one concern lifted verbatim from
SecurityUtility:
- PemReader        — loadCertificatesFromPemFile/Stream + loadPrivateKeyFromPemFile/Stream.
- JcaProviders     — getProvider/isBCFIPS + BC/Conscrypt provider constants and the
                     Conscrypt hostname-verifier workaround; resolveProvider and the
                     TrustManager processing are package-private (only JdkSslContexts uses
                     them).
- JdkSslContexts   — createSslContext(...) JDK SSLContext assembly, composing PemReader,
                     JcaProviders and the existing KeyStoreHolder.

This commit is purely additive; SecurityUtility is untouched and still compiles. Callers
migrate in the follow-up commit, and SecurityUtility (plus the dead helpers) is removed
after that. New package uses org.apache.pulsar.common.util.tls (not ...common.tls) to
avoid a split package with pulsar-common-api's org.apache.pulsar.common.tls.

Assisted-by: Claude Code (Opus 4.8)

…vider, not a JCA crypto provider

jsseProvider selects the provider that builds the TLS SSLContext
(SslContextBuilder.sslContextProvider) — a JSSE role. The previous wording
mis-framed it as a "JCA crypto provider" and used BCFIPS/PKCS#11 as example
values, but a crypto-only provider such as BCFIPS exposes no SSLContext.TLS and
cannot be named as the jsseProvider directly.

Reframe the javadoc, @ApiModelProperty/@FieldContext descriptions, wiring
comments, and pip-478.md (Motivation apache#4, Goal #5, out-of-scope, the SPI/design
and Configuration sections, and the v4 sslProvider->jsseProvider migration):
- jsseProvider names the JSSE (SSLContext) java.security.Provider that builds
  the SSLContext on the JDK engine (SslProvider.JDK + sslContextProvider),
  taking precedence over the factory engine choice.
- FIPS example is now jsseProvider=BCJSSE (the BouncyCastle JSSE provider from
  bctls-fips), with the FIPS-140-validated BC-FIPS provider registered
  separately as the crypto provider BCJSSE delegates to.
- Drop BCFIPS/PKCS#11 as jsseProvider VALUE examples; the v4-migration example
  values are the JSSE providers Conscrypt/SunJSSE.

Also update BCFIPS test tokens to BCJSSE in the propagation/mapping tests (they
assert the config is carried, never resolve a provider), keeping the eager
PulsarAdmin test on the resolvable SunJSSE. The JcaProviders utility keeps its
name and generic JCA/JCE role.

Assisted-by: Claude Code (Opus 4.8)

…on-default value"

Two documentation reconciliations in pip/pip-478.md:

- Break summary (apache#4): the PIP-337-removed BREAKING CHANGE bullet listed only the
  v4 builder-method source break and framed ClusterData as a metadata-model
  removal. Add the ClusterData brokerClientSslFactoryPlugin/...Params API
  accessors + builder methods (another public-API source break) and the
  pulsar-admin clusters --tls-factory-plugin / --tls-factory-plugin-params
  CmdClusters CLI options that wrote them, so the migration guidance is not
  understated. (The detailed removal-impact table already inventoried these.)

- "Non-default value" (#6): give the removed-key validation a precise definition
  matching the implementation — a *Plugin key is tolerated (treated as unset)
  when blank or equal to the old default FQCN
  org.apache.pulsar.common.util.DefaultPulsarSslFactory, and rejected otherwise;
  a *PluginParams key has no default, so any non-blank value is rejected. Make
  the config-file removed-key wording consistently "stale, non-default"
  (the separate ClusterData metadata lenient-drop case stays "stale value",
  since the removed-key validation does not run on a metadata read).

Assisted-by: Claude Code (Opus 4.8)